Ron Jeffereies 的 XP Diagram，很多人都看過，但不是每個人都知道他為什麼要畫成這個樣子：

上圖分成三層：最內層是工程的實踐，中間層是團隊規範，最外層是流程管理。為什麼工程實踐要放在最中間？我們先來看裡面有什麼東西：

Simple Design

Kent Beck 等先進一而再、再而三的告誡我們，要簡單設計。原因很簡單，你根本不知道未來需求會怎麼變化，為未知的未來保留彈性是不切實際的。萬一未來與你的預期不同（通常都會不同），那你一開始做的努力就全都白費了。

簡單設計還有一個好處：好讀。Uncle Bob 曾說，讓程式好懂，比讓程式跑得快重要。因為需求會改，跑得快的程式如果沒人看得懂，需求稍微改動一下，整段就廢了，再快又管何用？

另外，好讀也就好測了。假如你的每段程式都好測，自然也就不容易花太多時間改測試，效率自然也能提升了。

Test Driven Develoment

很多人對 TDD 有個誤解，以為 TDD 旨在測試。非也、非也。TDD 重點還是在開發（Development），只是拿測試來驅動而已。為什麼非得用測試來驅動不可？原因還是出在「理解」上。

一開始還沒寫 Code 時，寫出來的 Test Case，請問是要「測」什麼東西？沒東西對吧？因此，這時的 Test Case，目的就不是為了要測試，而是要「假設」。

我「假設」輸入名字，系統會回傳生日；我「假設」輸入身高體重，這計算機會回傳 BMi；我「假設」輸入國曆日期，這日曆會告訴鄉農曆日期為何，…等。在真正程式還沒寫出來前，這些都只是假設。等到待會程式寫完，我就可以跑一遍測試來驗證我的假設對不對。

在假設被重複驗證了幾千幾萬次都成功後，人們就可以相信這段程式是對的了。這就是我們從小學到大的「科學」了。

先寫測試還有一個最大的好處：好用。

因為你先寫了測試，你就假設了用戶會怎麼使用你的程式。試問，這樣一來，你要怎麼寫出不好用的程式？不可能吧？又不是吃飽太閒。如果真的你的程式介口不好用，你一開始測試根本就寫不出來。這是你就可以不用寫程式了，趕快改設計吧！